Method and apparatus for gps based slope determination, real-time vehicle mass determination, and vehicle efficiency analysis

ABSTRACT

Three dimensional GPS or vehicle position data is used to determine a slope the vehicle is traveling over at a specific point in time. The slope data can then be combined with other metrics to provide an accurate, slope corrected vehicle mass. The vehicle mass can then be used along with other vehicle data to determine an amount of work performed by a vehicle, enabling s detailed efficiency analysis of the vehicle to be performed. To calculate slope, horizontal ground speed (V HGS ) can be calculated using the Pythagorean Theorem. One can take the Z/Up magnitude and divide it by the horizontal ground speed. Replacing Z, x and y with directional vectors enables one to calculate slope. The slope data is then used to determine the mass of the vehicle at that time. Pervious techniques to calculate mass did not factor in slope, and thus are not accurate.

This application is based on a prior copending provisional applicationSer. No. 61/580,190, filed on Dec. 23, 2011, the benefit of the filingdate of which is hereby claimed under 35 U.S.C. §119(e).

BACKGROUND

As the cost of sensors, communications systems and navigational systemshas dropped, operators of commercial and fleet vehicles now have theability to collect a tremendous amount of data about the vehicles thatthey operate, including how the vehicles are being driven by the driversoperating such vehicles.

Unfortunately, simply collecting such data does not automaticallytranslate into cost savings. It would be desirable to provide such fleetoperators with additional tools in order to derive a benefit from thewealth of data that can be collected. Preferably, such tools can be usedto provide feedback to drivers to enable the fleet operator to encouragedriving habits leading to cost savings. Such a tool might thus be usedto develop objective criteria that could be used encourage and provideincentives to drivers to improve their performance in operating thevehicles in a fleet.

SUMMARY

One aspect of the novel concepts presented herein is a method ofproducing a numerical ranking of a driver's performance based on aplurality of metrics (recognizing that the concepts disclosed hereinalso encompass the use of only a single metric), and then sharing thosemetrics on a hosted website, such that the drivers can compare theirperformance metrics to those of their peers. Fleet operators can usethese performance metrics as incentives, by linking driver pay withperformance. Such a method comprises the steps of automaticallycollecting a plurality of metrics while a driver is operating a vehicle,automatically determining a numerical value for each metric,automatically combining the numerical values for the plurality ofmetrics to achieve a numerical performance value, and normalizing thenumerical performance value to achieve a numerical ranking of thedriver's performance while operating a vehicle, and then posting thedriver performance data to the hosted website.

In at least one related embodiment, fleet operators will pay driversusing a mileage component (i.e., paying drivers a fixed rate per loadedmile), while also making additional payments to drivers meetingpredefined performance characteristics. In at least one relatedembodiment, only drivers having top ranking performance metrics (such asdrivers having performance scores in the top 10% of the fleet, or the 25drivers having the best performance scores in the fleet, recognizingthat such specific examples are not intended to be limiting) will beeligible for the performance pay. In at least one other relatedembodiment, any driver in the fleet will be eligible for performancebonus pay once they have met a predefined performance metric.

While many embodiments will employ a single normalized numericalperformance score (i.e., a numerical score that combines severaldifferent metrics together), it should be recognized that in someembodiments performance pay can be linked to specific performancemetrics. For example, consider a fleet operator who has many routesinvolving mountainous terrain, and that fleet is experiencing excessingbrake wear/failure over those routes. That operator may want to linkperformance pay to brake operating temperature for a period of time toinduce drivers operating over those routes to pay more attention tobrake temperature. Such a focused review of driver performance data fora defined period of time will be referred to herein and in the claimsthat follow as a campaign. Where a campaign emphasizes a performancemetric such as brake temperature, the campaign can be designed to scoredrivers' performance in that campaign based only on the target metric(or metrics), such as brake temperature, or an existing normalizedperformance score can be modified so that the target metric (in thiscase, brake temperature) is more heavily weighted than normal.

It should be recognized that campaigns can be metric specific, or can bebased on a single normalized score, but will generally share in commonthe characteristic of being implemented for a defined period of time.Drivers will learn to associate such campaigns with opportunities toincrease their pay by meeting the performance goals of individualcampaigns. In some embodiments, campaign participants are limited todrivers in a specific fleet (i.e., an intra-company or intra-fleetcampaign). In such embodiments, that fleet generally will be paying theperformance bonuses for the campaign. In other embodiments, campaignparticipants are not limited to drivers in only one specific fleet(i.e., an inter-company or inter-fleet campaign). In such an embodiment,a third party may be paying the performance bonuses for the campaign.For example, companies providing goods and services to the trucking orvehicle transportation industry may sponsor such a campaign foradvertising purposes. A particular fleet operator seeking to attract theattention of drivers in other fleets might also be a sponsor of aninter-company campaign.

In at least one aspect of the concepts disclosed herein, the performancemetric is designed to facilitate comparison of driver performance dataacross different fleets, and different vehicles. This will enableindividual campaigns to include more participating drivers, which inturn will bring in more advertising revenue to fund bigger performancebonuses. In at least one embodiment, such a metric is mutually agreedupon by a plurality of different fleet operators. Adoption of a commonperformance metric across multiple fleets will enable top performingdrivers to be able to show their cumulative performance scores to otherparticipating fleet operators, providing an additional tool for fleetsto use when evaluating potential new hires. Such a common performancemetric will also enable participating fleet operators to appear moreattractive as potential employers than non-participating fleetoperators, who will not be offering the drivers the potential of earningthe additional performance based income (i.e., income in addition to theindustry standard pay by the mile driver compensation).

The concepts disclosed herein encompass embodiments in which individualfleet operators host their own website, where driver rankings in thatfleet can be compared. In other embodiments, the website is hosted by athird party, and multiple fleet operators participate. The third partycan offset their costs for operating the website by chargingparticipating fleet operators a fee, and/or by advertising revenue. Insome embodiments, all driver performance data is displayed in ananonymous format, so that individual drivers cannot be identified unlessthe driver shares their user ID. In some embodiments, drivers can onlycompare their score with drivers in their own fleet, while in otherembodiments drivers can see the performance data of drivers in otherfleets.

Having described the social networking/performance pay aspect of theconcepts disclosed herein, the following is directed to discussingexemplary techniques that can be used to acquire the performance data.However, it should be recognized that the social networking/performancepay concepts disclosed herein can be implemented using driverperformance metrics generated using different techniques, includingtechniques that do and do not rely on real-time transmission ofperformance data from participating vehicles to a remote data center. Atleast some of the concepts disclosed herein can be implanted using datarecorders that store data for a period of time before conveying thatdata to a data center for generating the driver performance data.

In at least one embodiment, the performance metric is based at least inpart from data collected from one or more engine control units (orvehicle computer(s)) in a vehicle operated by the driver whoseperformance is being measured.

In at least one embodiment, the performance metric is based at least inpart on fuel economy.

In at least one embodiment, the performance metric is based at least inpart on carbon footprint reduction.

In at least one embodiment, the performance metric is based at least inpart on minimizing fuel efficiency robbing behavior, including suddenbraking, rapid acceleration and downshifting too early.

In at least one embodiment, the performance metric is based at least inpart on maximizing fuel efficiency enhancing behavior, includingcoasting to a stop (instead of staying on the accelerator until the lastminute and then braking hard), driving at high average vehicle speedswith minimum time spent at maximum vehicle speed, driving in such amanner so as to achieve a high percent trip distance in top gear (90+%recommended), driving in such a manner so as to achieve a high percentdistance in cruise control, driving in such a manner so as to achieve aminimum percent idle/PTO operation, driving in such a manner so as toachieve a minimum service brake activity, driving in such a manner so asto achieve a relatively low number of sudden decelerations, and drivingin such a manner so as to achieve a relatively low number of servicebrake actuations/1000 miles.

In at least one embodiment, the commonly adopted performance metric isbased on the amount of vehicle work performed. In at least oneembodiment, such a metric includes using vehicle position derived slopedata to determine a vehicle's mass at a plurality of different timesduring the operation of a vehicle, and then using the mass to calculatework. The vehicle position data is generated by a position sensingsystem including a component (such as a receiver) disposed in thevehicle. An exemplary position sensing system is the Global PositioningSystem (GPS). The GPS system is a space-based satellite navigationsystem that provides location and time information in all weather,anywhere on or near the Earth, where there is an unobstructed line ofsight to four or more GPS satellites. It is maintained by the UnitedStates government and is freely accessible to anyone with a GPSreceiver. It should be understood that when the term GPS is used hereinand the claims that follow to refer to a component located at a vehicle,that such a component is a receiver for receiving satellite signals fromthe GPS system. Further, it should be understood that the conceptsdisclosed herein can be implemented using different types of vehicleposition sensing systems, such as the Russian Global NavigationSatellite System (GLONASS), the planned European Union Galileopositioning system, the Chinese Compass navigation system, and theIndian Regional Navigational Satellite System, and similar such systemsas they are developed. The concepts disclosed herein can also beimplemented by relying on basic triangulation of signals received fromterrestrial based transmitters (such as cell towers), should sufficienttransmitters be available (and should the vehicle position resolutionobtainable using such technology be generally comparable with thatavailable from satellite based systems).

Fundamentally, GPS systems calculate velocity in three components (X, Y,Z or N/S, E/W, and Up/Down) based on a Doppler shift of the GPSsatellite signals. Scalar speeds can then be calculated from those threecomponents. For example, absolute speed or actual vehicle speed can bedetermined, as well as ground speed based on the shortest distancebetween two points (i.e., based on distance as the crow flies).Horizontal ground speed (V_(HGS)) can be calculated using thePythagorean Theorem. To calculate a grade (G) the vehicle is travelingover (as a percentage), one can take the Z/Up magnitude and divide it bythe horizontal ground speed. Replacing Z, x and y with directionalvectors (such as Up for Z, West for x and North for y, recognizing thatsuch directional vectors are exemplary, and may change based on theactual GPS data collected from the vehicle) enables one to calculateslope. The slope data is then used to determine the mass of the vehicleat that time. Pervious techniques to calculate mass use torque output,engine RPMs, and vehicle velocity (scalar vehicle speed values can beused in place of velocity) to calculate a vehicle's mass or weight, butdid not factor in slope, and thus are not accurate over routes includingvariable slopes (which most routes include). An improved mass metrics(by including the GPS derived slope data in a mass calculation) enablesa more accurate weight based or work based performance metric to beprovided.

In at least one exemplary embodiment, where the driver performancemetric is based on a plurality of different parameters or metrics, eachone of the plurality of metrics will correspond to a different aspect ofthe driver's performance while operating a vehicle. Those of ordinaryskill in the art will readily recognize that a number of different typesof sensors are commonly integrated into commercial, passenger, and fleetvehicles. Such sensors can readily collect a wide variety of operationaldata that are related to driver performance. For example, one suchmetric is idle time of a vehicle. Excessive idling time generatesincreased emissions, increased fuel consumption, and increased enginewear. From the point of view of the fleet operator, drivers who operatevehicles so as to incur relatively greater idle times exhibit a lowerperformance compared to drivers who do so while incurring relativelyless idle time. Additional performance metrics related to both vehicleand driver performance include the amount of time the vehicle isaccelerating during the operation of the vehicle by the driver, theextent of such acceleration, the amount of time the vehicle isdecelerating during the operation of the vehicle by the driver, theextent of deceleration, whether (or how often) a driver deviates from apredefined route, and whether (or how often and to what extent) a driverexceeds a speed limit. Drivers who accelerate and decelerate often andaccelerate or brake excessively are likely to increase fuel consumption,emissions, engine and/or brake wear, as compared to drivers who are moreable to accelerate and decelerate modestly, and who are more able tomaintain a constant speed.

By combining a plurality of vehicle metrics related to driverperformance, a single numerical score or numerical ranking can be usedto provide feedback to individual drivers. Such a numerical ranking canbe used as a management tool to improve driver performance. For example,drivers with relatively poor numerical ranking scores can receivecounseling or warnings, which should lead to an improvement in theirperformance, while drivers receiving relatively better scores receivepraise or bonuses that encourage them and others to maintain or improvegood performance in operating a vehicle. Comparing such scores acrosscompanies or between individual branches of a company can be used as acontest or as a motivational tool, where drivers with relatively betterscores earn prizes or public praise. For example, a fleet operator couldregularly post a list of driver performance rankings in company breakrooms, so that drivers can compare their individual performance rankingswith one another (note the concepts disclosed herein also encompassposting such scores on a website).

Essentially, for each metric collected, a numerical value will bedetermined for that metric. Different metrics can be weighteddifferently, according to the preference of the fleet operator. Forexample, if a fleet operator is particularly concerned about reducingexcessive idle time, but is less concerned about drivers' accelerationand deceleration habits, idle time can weighted more significantly, tohave a greater effect on the numerical ranking determined for thedrivers than acceleration and deceleration metrics. Thus, in that case,increased idle time will have a greater proportional negative effect ona driver's overall score, than will excessive acceleration anddeceleration of a vehicle.

Normalizing the combined numerical scores for each metric is important;as such normalization enables the numerical rankings for differentdrivers to be compared. In one embodiment, the normalization is based ondividing the combined rankings by the distance over which the driver hasoperated the vehicle. For example, the drivers' combined numericalvalues for each metric can be divided by the number of miles over whichthe driver has operated vehicle. In another embodiment, thenormalization is based on dividing the combined rankings by the lengthof time the driver has operated a vehicle. For example, a driver'scombined numerical values for each metric can be divided by the numberof hours the driver has operated a vehicle.

Those of ordinary skill in the art will readily recognize that a varietyof different valuation paradigms can be implemented for determining anumerical value for each metric. Under some paradigms, a relativelyhigher normalized combined total will represent relatively better driverperformance, while under other paradigms a relatively lower normalizedcombined total will represent relatively better driver performance. Thespecific valuation paradigm employed is less important than the aspectof the present invention directed to providing a numerical value thatcan be used to evaluate driver performance, where the numerical value isbased on measurable metrics corresponding to a driver's performancewhile operating a vehicle. It should also be recognized that theconcepts presented herein can be applied to other types of equipment,such as heavy machinery and heavy construction equipment (backhoes,excavators, bulldozers, etc.), as well as to other types of equipment ormachinery that an operator controls, so long as the various aspects ofthe operator's performance can be sensed and the results used todetermine a numerical value representative of the overall quality withwhich the operator controls the equipment or machinery. It should alsobe recognized that the concepts provided herein can also be beneficiallyimplemented in other types of vehicles, including automobiles (such asrental car fleets, government vehicles, and fleet vehicles assigned tosales representatives or other employees of a business).

As noted above, one of the metrics that can be beneficially employedrelates to determining if a driver has deviated from a predefined route.This metric can be automatically determined by providing predefinedroute data comprising geographical coordinates, automatically collectinggeographical coordinate data while the driver is operating the vehicle(for example using a global positioning satellite (GPS) receiver), anddetermining if the driver has deviated from the predefined route bycomparing the collected geographical coordinate data with the predefinedroute data.

Yet another metric that can be beneficially employed relates todetermining whether a driver has exceeded a speed limit, which can beautomatically determined in several different fashions. In oneembodiment, it can be determined if a driver has violated the speedlimit by providing a baseline speed limit value (such as 60 miles anhour, for vehicles primarily operated on freeways), automaticallycollecting vehicle speed data while the driver is operating the vehicleon freeways, and determining if the driver has deviated from thebaseline speed limit value by comparing the collected vehicle speed datawith the baseline speed limit value (or distance traveled per unittime). In a different embodiment, the step of determining if the driverhas violated the speed limit comprises the steps of providing predefinedroute data comprising geographical coordinates and speed limitsassociated with each geographical coordinate, automatically collectinggeographical coordinate data and vehicle speed data while the driver isoperating the vehicle, and determining if the driver has violated thespeed limit by comparing the collected geographical coordinate data andvehicle speed data with the predefined route data for which the speedlimit is specified at different portions of the route.

It should be recognized that the steps of collecting the plurality ofmetrics and processing the plurality of metrics to determine thenumerical ranking of the driver's performance can be implemented inphysically different locations. In one embodiment, the plurality ofmetrics are automatically collected by the vehicle, and then transmittedto a remote computing device for processing. The metrics can betransmitted to the remote computing device in real-time, or can be savedin a memory in the vehicle and later transmitted to the remote computingdevice for processing, for example, when the vehicle is returned to acentral garaging facility. In other embodiments, processing of theplurality of the metrics occurs within the vehicle. Where the processingof the plurality of metrics occurs within the vehicle, the driver'scurrent performance ranking can be displayed in real-time to the driverto provide immediate feedback to help the driver improve performancewhile operating a vehicle. This approach would be analogous to providingreal-time fuel mileage estimates to a driver based on current vehicleoperating conditions. Providing drivers with feedback in real-time willenable drivers to correct driving habits while operating the vehicle,leading to an improved performance ranking. In such an embodiment, itwould be desirable to enable the driver to review the metricsresponsible for decreasing a driver's performance ranking. For example,if the driver's current performance ranking is relatively low becausethe driver is frequently accelerating and decelerating, rather thanmaintaining a constant speed, the display provided to the driver can becustomized to indicate the specific metrics responsible for the lowerthan desired performance ranking.

This Summary has been provided to introduce a few concepts in asimplified form that are further described in detail below in theDescription. However, this Summary is not intended to identify key oressential features of the claimed subject matter, nor is it intended tobe used as an aid in determining the scope of the claimed subjectmatter.

DRAWINGS

Various aspects and attendant advantages of one or more exemplaryembodiments and modifications thereto will become more readilyappreciated as the same becomes better understood by reference to thefollowing detailed description, when taken in conjunction with theaccompanying drawings, wherein:

FIG. 1 is a high level flow chart showing the overall method stepsimplemented in accord with one exemplary embodiment for achieving theconcepts disclosed herein;

FIG. 2 is a more detailed flow chart showing method steps implemented inan exemplary preferred embodiment;

FIG. 3 schematically illustrates a vehicle that includes a plurality ofsensors configured to collect the required metrics;

FIG. 4A is a functional block diagram illustrating the functionalelements of an embodiment in which the metrics are processed within thevehicle to obtain the driver's performance ranking, for example, inreal-time;

FIG. 4B is a functional block diagram illustrating the functionalelements of an embodiment in which the metrics are processed by acomputing device remote from the vehicle to obtain the driver'sperformance ranking;

FIG. 5 schematically illustrates the interior of a vehicle configuredwith a display to provide the driver with the performance ranking inreal-time;

FIG. 6 schematically illustrates a vehicle that includes a GPS unitconfigured to collect GPS data that can be used to provide a pluralityof metrics for use in determining a driver performance ranking in accordwith one aspect of the concepts disclosed herein;

FIG. 7 is a flow chart showing method steps implemented in an exemplarypreferred embodiment, where GPS data are used to provide a plurality ofmetrics used to determine the driver's performance ranking;

FIG. 8 is a flow chart showing method steps implemented in accord withone aspect of the concepts disclosed herein, the method stepsrepresenting an exemplary technique used to implement that aspect, theaspect comprising using GPS or position data are used to determine aslope the vehicle is traveling over (in at least one embodiment, theslope data will in turn be used to calculate an accurate vehicle massmetric);

FIG. 9 is a functional block diagram graphically illustrating forcevectors acting on a vehicle, and how those vector can be used to solvefor vehicle mass, where the GPS derived slope represents a uniquemetric;

FIG. 10 is a flow chart showing exemplary method steps implementedaccording to one aspect of the concepts disclosed herein, where GPS orposition derived slope data is used to calculate a vehicle's mass at aplurality of intervals during the operation of a vehicle, and then usingthe vehicle mass to determine a cost per loaded mile;

FIGS. 11A-11C graphically illustrate vehicle performance histogramsgenerated derived in part using the GPS derived slope data of FIG. 8;

FIGS. 12A-12B graphically illustrate vehicle performance histogramsgenerated derived in part using the GPS derived slope data;

FIG. 13 is a flow chart showing exemplary method steps implementedaccording to one aspect of the concepts disclosed herein, in which apromotional driver performance campaign is implemented at a hostedwebsite;

FIGS. 14 and 15 are functional blocks diagram illustrating that thepromotional driver performance campaigns and bonuses of the method ofFIG. 13 can include drivers from a single fleet (intra-company) ordrivers from multiple fleets (inter-company);

FIG. 16 is a functional block diagram illustrating exemplary elements ina vehicle/driver performance monitoring system in accord with one aspectof the concepts disclosed herein;

FIG. 17 is an exemplary screen shot of a website hosting a promotionaldriver performance campaign;

FIG. 18 is a another functional block diagram illustrating exemplaryelements in a vehicle/driver performance monitoring system in accordwith one aspect of the concepts disclosed herein;

FIG. 19 is an exemplary computing environment for implementing some ofthe concepts disclosed herein; and

FIG. 20 is a functional block diagram of an exemplary telematics deviceadded to an enrolled vehicle to implement one or more of the methods ofFIGS. 1, 2, 7, 8 and 10.

DESCRIPTION Figures and Disclosed Embodiments are not Limiting

Exemplary embodiments are illustrated in referenced Figures of thedrawings. It is intended that the embodiments and Figures disclosedherein are to be considered illustrative rather than restrictive. Nolimitation on the scope of the technology and of the claims that followis to be imputed to the examples shown in the drawings and discussedherein. Further, it should be understood that any feature of oneembodiment disclosed herein can be combined with one or more features ofany other embodiment that is disclosed, unless otherwise indicated.

Non-Transitory Memory Medium

Many of the concepts disclosed herein are implemented using a processorthat executes a sequence of logical steps using machine instructionsstored on a physical or non-transitory memory medium. It should beunderstood that where the specification and claims of this documentrefer to a memory medium, that reference is intended to be directed to anon-transitory memory medium. Such sequences can also be implemented byphysical logical electrical circuits specifically configured toimplement those logical steps (such circuits encompass applicationspecific integrated circuits).

Exemplary Logic for Determining Driver Performance

FIG. 1 is a high level flow chart showing the overall method stepsimplemented in accord with one aspect of the concepts disclosed herein.In a block 10 a plurality of metrics related to driver performance areautomatically collected by a plurality of sensors incorporated into avehicle. Such metrics generally relate to driver operation of thevehicle, but may also simply include data related to the vehicle. Suchmetrics can include, but are not limited to, vehicle speed, vehicleacceleration, vehicle deceleration, engine RPMs, idle time, enginetemperature, coolant temperature, oil temperature, fuel consumption, andvehicle positional data. Those of ordinary skill in the art will readilyrecognize that many different metrics related to vehicle performance anddriver performance can be collected. Thus, it should be recognized thatthe specifically identified metrics are intended to be exemplary, ratherthan limiting. In a block 12, a numerical ranking of the driver'sperformance is determined based on at least some of the metricscollected.

FIG. 2 is a more detailed flow chart showing method steps implemented ina preferred embodiment, providing additional details as to how thenumerical ranking of the driver's performance can be determined. In ablock 14, a numerical value is assigned to each metric collected. Itshould be recognized that plurality of valuation schemes can beimplemented, and the specific scheme implemented is not critical. Itshould also be recognized that a fleet operator can perceive somemetrics to be more or less important to overall driver performance.Thus, individual metrics can be weighted differently. For example, onefleet operator may have little tolerance for drivers who exceed postedspeed limits and want to place great emphasis on this metric whendetermining the numerical ranking. Such a fleet operator can assignsignificantly more weight to the detection of a driver exceeding a speedlimit than to the detection of a driver incurring excessive idle time.Regardless of the specific valuation scheme implemented, a numericalranking will be determined for each metric collected. In a block 16, thenumerical rankings for each metric are combined. In a block 18, thecombined numerical values for each metric are normalized, to enableperformance rankings for different drivers to be more equitablycompared. In one embodiment, the normalization is based on a distanceover which a driver has operated a vehicle. In another embodiment, thenormalization is based on an amount of time the driver has operated avehicle. This normalization enables the output of the normalizedcombined total to be provided as a numerical ranking in a block 20indicating a driver's performance. Note that the valuation schemeimplemented will determine whether a specific numerical value isindicative of a relatively good performance or a relatively poorperformance. Under some valuation schemes, relatively higher combinedand normalized numerical rankings are generally indicative of relativelybetter driver performance. In other valuation schemes, relatively lowercombined and normalized numerical rankings are generally indicative ofrelatively better driver performance.

FIG. 3 schematically illustrates a vehicle including a plurality ofsensors configured to collect the required metrics. A vehicle 22, suchas a bus or a truck, includes a plurality of sensors 24 a-24 h. Itshould be recognized that the specific number of sensors, and thespecific types of sensors and types of data collected by the sensors,are not critical, so long as the sensors collect data for the desiredmetrics. As noted above, a plurality of different metrics have beenspecifically identified, however it should be recognized that suchmetrics are intended to be exemplary, and not limiting on the conceptsdisclosed herein. In the disclosed exemplary embodiment, each sensor iscoupled to a CPU 26 (which, as described in greater detail below, may insome of embodiments be replaced with (or provided in addition to) atransmitter).

FIG. 4A is a functional block diagram 28 a illustrating the functionalelements of an exemplary embodiment in which the metrics are processedwithin the vehicle to obtain the driver's performance ranking. Thevehicle is equipped with sensors 30 configured to collect the requiredmetrics. The sensors are logically coupled with an onboard vehicle CPU34, which is configured to implement the method steps generallydescribed above. CPU 34 is logically coupled to a memory 32 in which arestored the machine instructions that are executed by the CPU to carryout these logical steps. The plurality of metrics collected by sensors30 can also be stored in memory 32. A (preferably optical or wireless)transmitter 36 (or other data link) can be included to enable either theplurality of metrics or the driver's performance ranking to becommunicated to a remote computing device. An optional display 38 can beincluded in the vehicle to provide real-time feedback to the driver (bydisplaying the driver's performance ranking in real-time). As discussedabove, if display 38 is implemented, it is desirable to provide theability for the driver to determine which metrics are having the mostimpact on the driver's performance ranking.

FIG. 4B is a functional block diagram 28 b illustrating the functionalelements of an exemplary embodiment in which the metrics are processedby a computing device to obtain the driver's performance ranking, wherethe computing device is remote from the vehicle. Once again, the vehicleis equipped with sensors 30 configured to collect the required metrics.The sensors are logically coupled with an onboard vehicle CPU 34, whichis configured to transmit the collected metrics to remote computingdevice 39 through transmitter 36 (or other data link). In a particularlypreferred embodiment, transmitter 36 is a wireless transmitter. In suchan embodiment, the method steps generally described above for processingthe collected metrics can be executed by the remote computing device.CPU 34 is logically coupled to memory 32 in which the collected metricscan be stored, if the metrics are not to be transmitted to the remotecomputing device in real-time. Even if the metrics are transmitted tothe remote computing device in real-time, such metrics can be stored inmemory 32 as a backup in case the transmission is not successful. Insuch an embodiment, a display is not likely to be beneficial, unless theremote computing device is configured to transmit the calculatedperformance ranking back to the vehicle for display to the driver.

FIG. 5 schematically illustrates the interior of a vehicle configuredwith a display 40 to provide the driver with a performance ranking inreal-time. As discussed above, such a display can be implemented by theembodiment schematically illustrated in FIG. 4A. While FIG. 5 shows asingle numerical performance ranking being displayed, it should beunderstood that the concepts disclosed herein encompass displaying aplurality of different metrics (at one or in rotation), as well asdisplaying a cost per loaded mile metric, which is discussed in detailbelow in connection with FIG. 10. The cost per loaded mile metric can becalculated using the concepts disclosed herein at a remote computingdevice and conveyed back to the vehicle for display, or can becalculated using a processor in the vehicle.

FIG. 6 schematically illustrates a vehicle 22 a that includes a GPS unit44 configured to collect GPS data that can be used to determine aplurality of metrics for use in determining a driver performanceranking. Such an embodiment enables the driver performance rankingdiscussed above to be generated without requiring individual oradditional sensors to be integrated into the vehicle (although it shouldbe recognized that such individual sensors could be used in addition to(or as an alternative source of) the data provided by the GPS unit, toprovide additional metrics used in determining a driver's performanceranking, generally consistent with the method steps described above withrespect to FIGS. 1 and 2). Vehicle 22 a, such as a bus or a truck (orautomobile, or construction equipment, generally as described above)includes GPS unit 44 coupled with an ignition system 42 of the vehicle.In an exemplary embodiment, the GPS unit will be coupled with theignition switch, such that it is assumed that when the ignition switchis on, the engine of the vehicle is actually running, and the GPS unitwill be activated. As described in greater detail below, GPS data can beused for a plurality of metrics, including idle time, deceleration timeand magnitude, acceleration time and magnitude, and to determine if adriver has violated a speed limit. The most basic GPS unit is able todetermine a position of the vehicle at a specific time. That positionalinformation can be used to calculate the speed of a vehicle bydetermining the change in position of the vehicle between two successivepoints in time, and to calculate the acceleration or deceleration of thevehicle by determining the change in speed of the vehicle over a timeincrement. More typically, GPS units automatically determine position,speed, and acceleration/deceleration internally, and these metrics wouldthen not need to be determined by an external computing device (remoteor local).

GPS unit 44 preferably includes or is connected to a wirelesstransmitter (not separately shown), such that the GPS data can bewirelessly transmitted to a remote computing device, preferably inreal-time. The remote computing device can be programmed to manipulatethe GPS data to determine a plurality of metrics, which can then be usedto calculate a driver's performance ranking, generally as describedabove. It should be recognized that as an alternative, GPS unit 44 caninclude an onboard memory, such that the GPS data are stored in the GPSunit, to be uploaded to a remote computing device at a later time (forexample, using a wireless or hardwired data link). Significantly, GPSunit 44 enables driver performance rankings to be determined, even ifthe vehicle is not equipped with separate other sensors of the metricdata or an onboard computer (as are required in the embodiments of FIGS.3, 4A, and 4B). It should be understood that the concepts disclosedherein encompasses coupling such a GPS unit to vehicle sensors and/or avehicle data bus, such that driver/vehicle performance data collected byother vehicle sensors can be combined with GPS data and conveyed to aremote computing site. While not specifically shown in FIG. 6, it shouldbe understood that GPS unit 44 can include a processor that uses GPSdata and sensor data collected from the vehicle to calculate performancemetrics, which are then combined with GPS data and conveyed to theremote computing site. One such metric is GPS derived slope data,discussed in detail in below in connection with FIG. 8. Such performancemetrics calculated by a processor in the vehicle (whether or not thatprocessor is associated with a GPS unit, or is a separate processor inthe vehicle) can be displayed in the vehicle, as well as (or in lieu of)being conveyed to a remote computing device.

FIG. 7 is a flow chart showing method steps implemented in one exemplaryembodiment when GPS data are used to calculate a plurality of metricsused to determine the driver's performance ranking. In a block 46, thevehicle ignition is switched on (and it is assumed that the engine isrunning), thereby powering on the GPS unit. In a block 48, the GPS unitcollects GPS data (information corresponding both to a particular pointin time and a specific geographical position that the vehicle occupiesat that specific point in time). In a block 50, the GPS data aretransmitted to a remote computing device. As noted above, the GPS dataare preferably transmitted to the remote computing device in real-time.However, it should be recognized that the GPS data can be temporarilystored within the GPS unit (or in a memory electronically coupled to theGPS unit), and transferred to the remote computing device at a latertime. In a block 52, the remote computing device uses the GPS data tocalculate an idle time metric. Because the GPS unit is only on when theignition switch is on and the engine of the vehicle is assumed to berunning, an assumption can be made that the idle time equals theaccumulated time that the GPS unit is on, but the vehicle is notchanging position.

In a block 54, the remote computing device uses the GPS data todetermine metrics corresponding to acceleration time and accelerationmagnitude. In a block 56, the remote computing device uses the GPS datato determine metrics corresponding to deceleration time and decelerationmagnitude. In a block 58, the remote computing device uses the GPS datato determine whether a driver has exceeded a speed limit. Those ofordinary skill in the art will readily recognize that several mappingdatabases exist that include a database of speed limits and which enablea speed limit for a specific portion of a route being driven by avehicle to be determined based on a particular geographical coordinateof the vehicle following that route. GPS data includes an indication ofthe speed of the vehicle at a particular time while the vehicle is at aparticular geographical location. Once the vehicle speed has beendetermined for a particular geographical position, a database can beconsulted to determine the speed limit associated with that positionalong the route, thereby enabling a determination to be made as towhether the driver has exceeded the speed limit. In a block 60, theplurality of metrics calculated from the GPS data are used to determinethe driver's performance ranking, generally as described above inconnection with FIGS. 1 and 2.

It should be recognized that the GPS data can be used to calculate fewermetrics than those described above in connection with FIG. 7, and thatthe metrics specifically identified in FIG. 7 are intended to beexemplary, rather than limiting. Furthermore, if the vehicle includesother sensors for determining metrics, the sensor data can also beforwarded to the remote computing device to be used in calculating thedriver's performance ranking, also generally as described above.Furthermore, it should be recognized that rather than (or in additionto) transmitting the GPS data to a remote computing device, the GPS datacan be conveyed to a computing device on the vehicle, for determiningthe driver's performance ranking.

Preferably, performance rankings are determined for each driver in acompany (or each driver of a vehicle for which driver performance is ofinterest), and posted publicly so that drivers can compare each other'sindividual performance rankings. The public display of driverperformance is expected to provide an incentive for drivers to improvetheir driving performance rankings.

It should be understood that the concepts disclosed herein encompassmany differ types of performance metrics, and different techniques forcollecting them. In at least some embodiments, as exemplified by FIG. 6,the performance metrics are transmitted from the vehicle to a remotecomputing device by a wireless data link enabled GPS unit (such as aGSM/GPS), that also collects location data during the vehicle'soperation. It should be understood that such performance metrics canalso be collected using a data recorder that does not have wireless datatransmission capability, such that data will need to be exported fromthe data recorder to a remote computing device periodically, or the datarecorder will need to be removed from the vehicle and coupled to acomputing device periodically to export the data used to calculate thedriver performance metric(s).

While specific parameters or metrics used to derive a driver performancemetric have been discussed above, it should be recognized that thefollowing different parameters/metrics are specifically encompassedherein. One or more embodiments in which the performance metric is basedat least in part from data collected from one or more engine controlunits (or vehicle computer) in a vehicle operated by the driver whoseperformance is being measured. One or more embodiments in which theperformance metric is based at least in part on fuel economy. One ormore embodiments in which the performance metric is based at least inpart on carbon footprint reduction. One or more embodiments in which theperformance metric is based at least in part on minimizing fuelefficiency robbing behavior, including sudden braking, rapidacceleration and downshifting too early. One or more embodiments inwhich the performance metric is based at least in part on maximizingfuel efficiency enhancing behavior, including coasting to a stop(instead of staying on the accelerator until the last minute and thenbraking hard), high average vehicle speeds with minimum time spent atmaximum vehicle speed, high percent trip distance in top gear (90+%recommended), high percent distance in cruise control, minimum percentidle/PTO operation, minimum service brake activity, low number of suddendecelerations, and low service brake actuation's/1000 miles.

Another aspect of the concepts disclosed herein is a technique tomonitor vehicle location data (i.e. GPS data) over time to determine theactual operating speed of a fleet vehicle. Many fleet operators have theability to define maximum speed parameters on their vehicles. Maximumspeed parameters are defined to enhance safety and to reduce fuel costs(statistics indicated that for heavy trucks every MPH over 62 MPHreduces fuel economy by 0.1 MPG). However, these speed settings can faildue to maintenance issues, or driver manipulations. The maximum speedsetting is based on understanding the size of the vehicle's tires. Ifduring maintenance a different size tire is used as a replacement, thepredefined speed settings will be inaccurate. Because drivers are oftenpaid by the mile, drivers have an incentive to defeat the maximum speedsettings, and drivers may encourage the use of different tire sizes, sothey can go faster than the maximum speed setting, to increase theirearnings. Drivers can also purchase and install aftermarket kitsdesigned to bypass speed governors, again so they can go faster than themaximum speed setting, to increase their earnings. The conceptsdisclosed herein encompass collecting GPS data during the operation of afleet vehicle, and analyzing the location and time parameters of thatdata to identify when a fleet vehicle exceeds a predefined maximumspeed. The GPS verified speed metric can be used as a driver performancemetric on its own, or be combined with other metrics to generate adriver performance metric.

Another aspect of the concepts disclosed herein is to monitor manualoverrides for cooling fans in fleet vehicles. Such cooling fans,generally controlled by a vehicle engine control unit (ECU) or vehiclecomputer, consume up to 50-70 HP, and measurably reduce fuel economy.Drivers who habitually override the automatic fan settings can consumeunnecessary amounts of fuel. Thus the concepts disclosed hereinencompass monitoring a driver's use of cooling fan manual override, tofacilitate an evaluation of a driver's performance, and to enabledrivers who use such overrides excessively to be identified and trainedto reduce their use of manual cooling fan overrides. The cooling fanmanual override metric can be used as a driver performance metric on itsown, or be combined with other metrics to generate a driver performancemetric.

Another aspect of the concepts disclosed herein is to monitor engineRPMs during a driver's operation of a vehicle. Over revving an enginecan lead to increased fuel use and engine wear. Drivers who habituallyover rev their vehicles engines can consume unnecessary amounts of fuel.Thus the concepts disclosed herein encompass monitoring the RPMparameters while a driver operates a vehicle, to facilitate anevaluation of a driver's performance, and to enable drivers whoconsistently over rev their vehicle's engines to be identified andtrained to reduce their over revving behavior. The over revving metriccan be used as a driver performance metric on its own, or be combinedwith other metrics to generate a driver performance metric.

Another aspect of the concepts disclosed herein is to monitor theshifting behavior during a driver's operation of a vehicle. Not runninga heavy truck in the highest possible gear when possible can lead toincreased fuel use and engine wear. Statistics indicate that every 10%drop of time in top gear results in a 0.5% MPG loss. Thus the conceptsdisclosed herein encompass monitoring shifting behavior while a driveroperates a vehicle, to facilitate an evaluation of a driver'sperformance, and to enable drivers who consistently under shift to beidentified and trained to reduce their over revving behavior. Theshifting pattern metric can be used as a driver performance metric onits own, or be combined with other metrics to generate a driverperformance metric.

Another aspect of the concepts disclosed herein is to monitor the amountif idle time during a driver's operation of a vehicle. Increased idletime leads to increased fuel use and engine wear. Thus the conceptsdisclosed herein encompass monitoring idle time behavior while a driveroperates a vehicle, to facilitate an evaluation of a driver'sperformance, and to enable drivers who excessively allow their vehicleto idle to be identified and trained to reduce their excess idlebehavior. The excessive idle metric can be used as a driver performancemetric on its own, or be combined with other metrics to generate adriver performance metric.

Another aspect of the concepts disclosed herein is to monitor a loadplaced upon a vehicle's engine during a driver's operation of a vehicle.While related to RPM, load is not equivalent. An estimation of engineload is sometimes calculated by a vehicle ECU, and differentmanufacturers use different combinations of parameters to calculateengine load, including but not limited to throttle position, RPM,manifold pressure, air flow, temperature, air conditioning clutchstatus, power steering pressure, and transmission gear status. Whereengine load is increased without performing more useful work (i.e.,carrying more cargo), increased fuel use and engine wear result withouta net benefit. Drivers who habitually operate their vehicles underhigher engine loads than required consume unnecessary amounts of fuel.Thus the concepts disclosed herein encompass monitoring engine loadwhile a driver operates a vehicle, to facilitate an evaluation of adriver's performance, and to enable drivers who consistently over loadtheir vehicle's engines to be identified and trained to reduce theirover loading behavior. The engine load metric can be used as a driverperformance metric on its own, or be combined with other metrics togenerate a driver performance metric.

Calculation of an Exemplary Performance Ranking

The calculation of an exemplary performance ranking is described belowin regard to one exemplary embodiment. It should be recognized that thisapproach for determining the performance ranking is not intended to belimiting, but rather to be illustrative of one contemplated valuationscheme and performance ranking implementation. In the exemplaryperformance ranking, a relatively higher numerical ranking value isgenerally indicative of relatively poorer driver performance. Thus, inthis example, the lower the numerical performance ranking, the betterthe driver's performance.

In this example, the sensor data are collected for various metricscorresponding to vehicle acceleration, vehicle deceleration, vehicleidle time, and vehicle speed. Each minute of acceleration time will beassigned one point. Each minute of deceleration time will be assignedone point. Each minute of idle time will be assigned one point. In thisexample, the fleet operator is also particularly concerned with driverswho violate speed limits on the freeway. Thus, each minute where thevehicle speed exceeds 60 miles an hour while the driver is driving thevehicle on the freeway will result in five points (the fleet operatorweighting excessive vehicle speed five times greater than the othermetrics). The points are added together to achieve a combined total. Thetotal is then normalized to derive a numerical ranking value for thedriver. As noted above, the normalization can be based on eitherdistance driven or time of operation, or a combination thereof.

Calculation of a Work Based Performance Ranking Using GPS Derived SlopeData

The concepts disclosed herein encompass using data collected during theoperation of a vehicle to calculate a weight of the vehicle, and thenusing the calculated weight in a performance analysis of the vehicle.The novel vehicle weight calculation disclosed herein employs in partvehicle position data collected while a vehicle is moving. The positionmetric can be automatically determined using a global positioningsatellite (GPS) receiver installed in the vehicle, to track thevehicle's change in position over time. It should be recognized that theGPS system is but one of a plurality of different vehicle positionsensing technologies that can be employed.

Fundamentally, GPS systems calculate velocity in three components (X, Y,Z or N/S, E/W, and Up/Down) based on a Doppler shift of the GPSsatellite signals. Scalar speeds can then be calculated from those threecomponents. For example, absolute speed or actual vehicle speed can bedetermined, as well as ground speed based on the shortest distancebetween two points (i.e., based on distance as the crow flies).

Horizontal ground speed (V_(HGS)) can be calculated using the followingrelationship based on the Pythagorean theorem:

V _(HGS) =√{square root over (x² +y ²)}  (1)

To calculate a grade (G) the vehicle is traveling over (as apercentage), one can take the Z/Up magnitude and divide it by thehorizontal ground speed, V_(HGS), which results in the followingrelationship:

$\begin{matrix}{G = \frac{100(Z)}{V_{HGS}}} & (2)\end{matrix}$

Replacing Z, x and y with directional vectors (such as Up for Z, Westfor x and North for y, recognizing that such directional vectors areexemplary, and may change based on the actual GPS data collected fromthe vehicle) results in the following relationship:

$\begin{matrix}{G = \frac{100({Up})}{\sqrt{W^{2} + N^{2}}}} & (3)\end{matrix}$

Once one has derived G as discussed above, very useful vehicleperformance metrics can be determined.

One exemplary use of the slope data is to determine the mass of thevehicle at that time. Mass is a useful metric that can be used as afeedback metric for controlling certain vehicle systems. Some vehicleengine control units (ECUs) use torque output, engine RPMs, and vehiclevelocity (noting that scalar vehicle speed can be used for velocity) tocalculate a vehicle's mass or weight (as used herein and in the claimsthat follow, the terms mass and weight are used synonymously, because onthe surface of the Earth, the acceleration due to gravity (the “strengthof gravity”) is approximately constant; thus the ratio of the weightforce of a motionless object on the surface of the Earth to its mass isalmost independent of its location, so that an object's weight force canstand as a proxy for its mass, and vice versa). That ECU weight/massdetermination technique is error prone, because it does not take intoaccount any slope conditions. Even though the ECU weight/massdetermination technique is error prone, the ECU weight/massdetermination technique mass estimation provides a metric that can beused to as a feedback metric for various vehicle systems, includingtransmission shift points, engine RPM control, and emission controls.Having more accurate mass metrics (by including the GPS derived slopedata in a mass calculation) will provide an improved mass metric. Theconcepts disclosed herein specifically encompass a GPS unit configuredto use GPS data to calculate slope, to use the slope data and othervehicle parameters to determine vehicle mass (generally as discussedbelow), and then to provide a GPS slope based vehicle mass metric to avehicle ECU to be used as a metric to control vehicle operation.

Vehicle mass can also be used as an analytical metric to determine howmuch work a vehicle has performed. Being able to accurately determinethe amount of work a vehicle performs will help vehicle operatorsanalyze their use patterns to seek out efficiency improvements. The GPSderived slope data enables more accurate vehicle mass calculations to bedetermined, which in turn will provide an improved vehicle performancedata set that can be mined to identify areas in which efficiencyimprovements could be made.

Having described the GPS based slope determination technique; thefollowing relationships will be used to obtain vehicle mass from the GPSdetermined slope (G). These relationships define the forces acting onthe vehicle, and include a force related to a grade the vehicle istraveling over, an aerodynamic force, a frictional force, and a forceapplied by the vehicle to overcome the forces acting on the vehicle. Theunderstanding of these forces is not new, but what is novel aretechniques disclosed herein to measure certain parameters that are usedto calculate such forces. Being able to measure those parameters, suchas a grade the vehicle is traveling over, enables more accurate forcecalculations to be performed, which in turn enables a betterunderstanding of vehicle operational efficiency.

It should be understood that with respect to calculating mass, theequations discussed below refer to the velocity of the vehicle as aparameter. Vehicle speed is a scalar quantity; whereas velocity is avector (velocity is the rate of change of the position of an object,equivalent to a specification of its speed and direction of motion). Inother words, speed describes only how fast an object is moving; whereasvelocity gives both how fast and in what direction the object is moving.In terms of using position data, such as GPS data, to determine slope,position data changing over time provides three-dimensional vectors(speed and direction) that can be used to derive slope, generally asdiscussed above. With respect to calculating mass, it is important torecognize that scalar values can be used in place of vectors, whilestill providing useful results. Thus, it should be understood that thescalar parameter of vehicle speed can be used in place of the velocityparameter discussed below when using the following relationships todetermine vehicle mass. Vehicle speed (which in the terms of vehiclearts is often inaccurately referred to as velocity) is generallyavailable in the vehicle from a vehicle ECU or speed sensor (most overthe road vehicles, such as trucks and buses, are equipped withrelatively accurate speed sensors). While the GPS unit can be used todetermine vehicle speed by tracking changes in position over time, ingeneral the resolution of vehicle speed measurements taken from vehiclespeed sensors is greater than a resolution of vehicle speed derived fromchanges in GPS data over time (or other position data), and thus the useof vehicle speed data from vehicle speed sensors is quite useful for thefollowing mass determination techniques.

A first force opposing a motion of the vehicle relates to a grade orslope the vehicle is traveling over, which can be defined using therelationship of Equation (4).

f _(grade) =m*g*G  (4)

where m is vehicle mass and g is the local gravitational field (i.e.,Earth's gravity).

A second force opposing a motion of the vehicle relates to aerodynamicforces acting on the vehicle, which can be defined using therelationship of Equation (5).

f _(areo)=½*p*C _(d) *A*ν ²  (5)

where ρ is air density, C_(d) is the coefficient of drag of the vehicle,A is the frontal area of the vehicle, and ν is the vehicle velocity(which can be obtained from the vehicle data bus as speed or from GPSdata).

A third force opposing a motion of the vehicle relates to frictionalforces acting on the vehicle, which can be defined using therelationship of Equation (6).

f _(Friction) =C _(rr) *m*g*(1−G)  (6)

where C_(rr) is the coefficient of rolling resistance of the vehicle(which is assumed to be constant), m is vehicle mass, g is the localgravitational field (i.e., Earth's gravity), and G is the slope, whichis calculated using the GPS data as discussed above.

The force generated by the vehicle to overcome these opposing forces canbe defined using the relationship of Equation (7).

$\begin{matrix}{f_{Applied} = \frac{\tau*\frac{N}{v}*\pi}{r}} & (7)\end{matrix}$

where τ is engine output torque (as measured at the vehicle by vehiclesensors/reported by the vehicle data bus), N is engine RMPs (as measuredat the vehicle by vehicle sensors/reported by the vehicle data bus), νis the vehicle velocity (which can be obtained from the vehicle data busor from GPS data), it is the mathematical constant defined as the ratioof any circle's circumference to its diameter, and r is the radius ofthe vehicles tires.

Vehicle mass is a parameter in the grade and frictional forcerelationships, of Equations (4) and (6), respectively. The massparameter itself can be defined using the relationship of Equation (8).

$\begin{matrix}{m = \frac{f_{Applied} - f_{Friction} - f_{Grade} - f_{Aero}}{\alpha}} & (8)\end{matrix}$

where m is vehicle mass and α is acceleration (which can be obtainedfrom the vehicle data bus or from GPS data). In an exemplary embodiment,acceleration is obtained from the vehicle sensors.

Equations (4)-(8) can be solved to obtain mass, as defined using therelationship of Equation (9).

$\begin{matrix}{m = \frac{f_{Applied} - f_{Aero}}{a + {g*\left( {C_{rr} + S - {C_{rr}*S}} \right)}}} & (9)\end{matrix}$

Note that the following parameters will be measured during vehicleoperation in order for mass to be calculated: velocity (or speed),torque, RPM. Those parameters, combined with the GPS derived slope data,and known parameters (gravity, air density, rolling resistance, frontalarea, drag, π (pi), and tire radius, such parameters can be programmedinto the a telematics device or processor at the vehicle) can be used bya processor in the vehicle to calculate mass. Velocity (or speed),torque, and RPM represent metrics that many vehicles already measureduring vehicle operation, and thus can be accessed by tapping into avehicle ECU or data bus. The concepts disclosed herein specificallyencompass a GPS unit (or other position sensing unit) including a dataport coupled to a vehicle ECU/data bus and a processor configured tocalculate a GPS derived slope metric (generally as discussed herein) anda vehicle mass metric (generally as discussed herein, using in part theGPS derived slope data).

Having an accurate mass parameter, determined in real-time during theoperation of the vehicle, will enable a more accurate measurement of thework being performed by the vehicle to be measured. The work metric canbe used as a driver performance metric on its own, or be combined withother metrics to generate a driver performance metric.

FIG. 8 is a flow chart showing method steps implemented in an exemplaryembodiment, where position data (such as GPS data) collected during theoperation of a vehicle is used to determine a slope or grade over whichthe vehicle is being operated. That grade then can be used to calculateother data, such as a weight or mass of the vehicle. In a block 120,three dimensional position data (longitude, latitude and elevation) iscollected during vehicle operation. In at least some embodiments, thatdata is conveyed from the vehicle to a remote computing site (i.e., amonitoring/data storage location) in real-time. In other embodiments,the position data is stored in a memory in the vehicle, to be conveyedto a remote computing site at a later time. In a block 122, the positiondata is used to determine horizontal ground speed, using therelationship of Equation (1). In a block 124, the horizontal groundspeed (from the GPS data) and the Z-axis position data is used todetermine the slope or grade, using the relationships of Equations (2)and (3).

In an optional block 126, the slope data is used to calculate a mass ofthe vehicle, using the relationship of Equation (9). In at least someembodiments, the data processing of blocks 122, 124, and 126 areperformed by a remote computing device. However, the concepts disclosedherein encompass embodiments where some or all of the data processing ofblocks 122, 124, and 126 are performed by a processor or logic circuitin the vehicle. In at least some embodiments in which the dataprocessing is implemented in the vehicle, the mass parameter is used byan ECU in the vehicle to control operating parameters of the vehicle.For example, vehicle mass can be used as a feedback parameter forcontrolling vehicle operations, including engine speed (RPM),transmission gear selection, and fuel flow/mixture (to control vehicleemissions). While using vehicle mass data used as a feedback parameterfor controlling vehicle operations has been implemented before, thoseimplementations have not used GPS derived slope data as a parameter todetermine vehicle mass.

FIG. 9 graphically illustrates force vectors acting on a vehicle,including a frictional force, an aerodynamic force, a grade/sloperelated force, and a vehicle applied force used to overcome the opposingforces. The forces are discussed above in connection with Equations(4)-(7), and those relationships can be used to use GPS derived slopedata to calculate vehicle mass, as shown in Equation (9).

FIG. 10 is a flow chart showing method steps implemented in an exemplaryembodiment, where GPS derived slope data and vehicle mass datacalculated using GPS derived slope data position data are used toanalyze vehicle performance, to determine a cost per loaded mile.Because the concepts disclosed herein provide an improved vehicle massparameter that is determined while a vehicle is operating, the analysisof the work performed by the vehicle, and the cost per loaded milecalculation, are more accurate than have been heretofore obtainableusing data derived by existing techniques. In a block 120, threedimensional position data (longitude, latitude and elevation) iscollected during operation of the vehicle. As noted above, in at leastsome embodiments, that data is conveyed from the vehicle to a remotecomputing site (i.e., a monitoring/data storage location) in real-time,while in other embodiments, the position data is stored in a memory inthe vehicle, to be conveyed to a remote computing site at a later time.In a block 123, fuel use and mileage data is collected during theoperation of the vehicle. In a block 126, GPS derived slope data is usedto calculate vehicle mass, generally as discussed above. Then, in ablock 127, the mileage data, fuel use data, and vehicle mass data areused to slope data is used to calculate a cost per loaded mile metric.

Fleet operators recognize that cost per loaded is a metric that can beanalyzed to improve the efficiency of their fleets, by allowing driverperformance to be evaluated, and by allowing different routes to beanalyzed, to determine the actual cost of servicing a particular route.While these concepts are not new, what is new is the improved vehiclemass metric that can be calculate in real-time while the vehicle isoperated, or at a later time, where the mass metric is available for theduration of the vehicle operating segment (or trip). Note that in theprior art, unless the vehicle was weighed during the trip (i.e., beforethe trip, after the trip, or during the trip at a scale stop) suchaccurate vehicle mass data was not available, so the cost per loadedmetric was error prone, or accurate based on data collected at only afew selected segments of the trip. The concepts disclosed herein arebased on collecting vehicle operational data (fuel use, mileage,position data, etc.) frequently (i.e., multiple times a minute, or atleast once every few minutes, such intervals being exemplary) so thatvehicle mass can be accurately calculated at almost any time during theoperation of a vehicle.

An exemplary data set collected from a vehicle will include time indexedposition data, engine RPM data, vehicle torque data, and vehicle speed.This data will be collected frequently (multiple times per minute, or aplurality of times over a ten minute period) while the vehicle isoperational. Note that vehicle speed can be determined by analyzingposition data over time, or can be measured using a vehicle sensor (notethat comparing vehicle speed obtained from vehicle sensors with vehiclespeed calculated based on GPS data can identify errors in the vehiclespeed sensor, which can be caused by incorrect tire sizes, or driveradded speed cheating devices designed to override vehicle speedgovernors). Such a data set can also include other types of vehicledata, including, but not limited to, data relating to the vehicletransmission (so drivers can be evaluated based on percentage of timespent in the most efficient gear), data relating to the vehicle brakingsystem (so drivers can be evaluated based on their braking behavior),data relating to the use of cooling fan overrides (so drivers can beevaluated based on how often they such an override that reduces fuelefficiency), data relating to idle time (so drivers can be evaluatedbased on percentage of time spent in wasting fuel by idling, noting thatidle time can be evaluated in light of position data, so that driversare not penalized for idling at traffic lights), data relating to theuse of a vehicle's cruise control system (so drivers can be evaluatedbased on percentage of time spent driving at fuel efficient speeds).Note this exemplary data set includes the data required to calculatevehicle mass using GPS derived slope data, generally as discussed above.

FIGS. 11A-11C graphically illustrate histograms that can be derivedusing the exemplary data set discussed above. These histograms can beused by fleet operators to evaluate the efficiency performance ofindividual drivers and/or individual vehicles, being operated overspecific routes (the routes being defined by the position data). EachFigure has a histogram based on a vehicle being operated with a heavyload, and a histogram based on a vehicle being operated with a lightload. In FIG. 11A, speed histograms show a percentage of time a vehicleis operated at specific speeds, enabling fleet operators to determinehow often the driver/vehicle is using the most efficient vehicle speeds.The histograms include bars that show load vs. speed, and time vs.speed. In FIG. 11B, RPM histograms show a percentage of time a vehicleis operated at specific RMP settings, enabling fleet operators todetermine how often the driver/vehicle is using the most efficientengine speeds. The histograms include bars that show load vs. RPM, andtime vs. RPM. In FIG. 11C, load histograms show a percentage of time avehicle is operated at specific load settings, enabling fleet operatorsto determine how often the driver/vehicle is placed under the mostdemanding loads. In exemplary embodiments, when appropriate, thehistograms of FIGS. 11A-11C can be generated using the vehicle masscalculated using GPS derived slope data, generally as discussed above.

FIGS. 12A and 12B graphically illustrate histograms that can be derivedusing the exemplary data set discussed above. These histograms can beused by fleet operators to evaluate the efficiency performance ofindividual drivers and/or individual vehicles, being operated overspecific routes (the routes being defined by the position data). Thehistogram of FIG. 12A includes bars that show the cost per loaded mileand MPG for 14 different trips (each trip being defined by a differentset of position data from the exemplary data set.). The histogram ofFIG. 12B includes bars that show the cost per loaded mile and MPG for 14different trips, with the data being normalized to a 30 ton load. Inexemplary embodiments, the histograms of FIGS. 12 and 12B are generatedusing the vehicle mass calculated using GPS derived slope data,generally as discussed above.

Hosted Website for Tracking Driver Performance Data

One aspect of the concepts disclosed herein is a hosted website,enabling drivers and fleet operators to monitor the performance ofdrivers, based on data collected during the drivers operation of avehicle. In at least one embodiment, drivers can compare theirperformance metrics to those of their peers, although the conceptsdisclosed herein also encompass embodiments where individual drivers canonly see their own performance scores. Fleet operators can use theseperformance metrics as incentives, by linking driver pay withperformance.

In general, one or more performance metrics are automatically collectedwhile a driver is operating a vehicle, and that data is used to generatea score or rating of the driver's performance. In at least oneembodiment, the score is normalized to enable driver scores from othertypes of vehicles to be compared. Then, the driver performance data isposted to the hosted website.

In at least one related embodiment, fleet operators will pay driversusing a mileage component (i.e., paying drivers a fixed rate per loadedmile), while also making additional payments to drivers meetingpredefined performance characteristics. The hosted website can be usedas a forum to enable drivers to track their progress in achieving theirpay for performance goals. Fleet operators will have a wide degree offreedom in designing pay for performance goals or campaigns. Forexample, Fleet A can design a campaign in which only drivers havingperformance scores in the top 10% of the fleet will earn performancepay. Fleet B can design a campaign in which only the top 25 scoring willearn performance pay during a particular campaign. Fleets can predefinethe amount of performance pay each driver can earn. Fleets can alsopredefine a performance pay pool, such that the share of the pool earnedby each driver is a function of the number of drivers meeting predefinedperformance goals for the campaign.

In at least one embodiment, the performance metric will be a work basedperformance metric whose calculation involves using vehicle massdetermined using GPS derived slope data, generally as discussed above.

It should be recognized that performance campaigns can be metricspecific (hard braking performance, idle time performance, such metricsbeing exemplary and not limiting), or can be based on a singlenormalized score (cost per loaded mile), but will share in common thecharacteristic of being implemented for a defined period of time.Drivers will learn to associate such campaigns with opportunities toincrease their pay by meeting the performance goals of individualcampaigns.

FIG. 13 is a flow chart showing method steps implemented in an exemplaryembodiment. In a block 62, the hosted website defines a campaign (notingthat the website host may be a fleet operator providing the website foronly their drivers, or the hosting website host may be offering thedriver performance campaign to drivers from multiple fleets). Parametersof the campaign being defined will likely include a duration of thecampaign, the prize or performance pay being offered, the eligible pooldrivers, and any rules governing disqualification (such as any safetyviolation or speeding ticket automatically disqualifying a driver),noting that such parameters are exemplary, and not limiting. Theconcepts disclosed herein encompass embodiments in which campaigns arefleet specific, such that only drivers from a specific fleet canparticipate in that campaign (in such an embodiment, the specific fleetis likely funding the prize, although some third party, such as afavored vendor, customer, or advertiser might offer to fund the prize).The concepts disclosed herein encompass embodiments in which campaignsare not fleet specific, such that drivers from multiple fleets canparticipate in that campaign (in such an embodiment, an advertiser ortransportation industry vendor might offer to fund the prize).

In at least one embodiment, the campaign duration is open ended, in thatthe hosted website will track a drivers' performance data over time, sothe driver can use that data to look for other employment opportunities.For example, fleets would likely compete among themselves for drivershaving a combination of experience and high performance rankings.

In a block 64, driver performance data is posted to the hosted website.The concepts disclosed herein encompass permutations and combinations ofthe following: embodiments in which fleet operators can view performancerankings for all of their drivers, but not drivers of other fleets,embodiments in which drivers can only view their own personalperformance ranking, embodiments in which drivers can view performanceranking for all of the drivers in their fleet, but not drivers of otherfleets, and very transparent embodiments, in which interested partiescan visit the website and peruse driver performance rankings with littlerestrictions.

In a block 66, at the end of the defined campaign, the winning driver(or drivers) are announced and paid a performance pay bonus. Note thatthe concepts disclosed herein can be extended to other types ofincentives, such as vacation time, paid travel, tickets to sportingevents, and/or goods and services.

As noted above, in some embodiments, campaign participants are limitedto drivers in a specific fleet (i.e., an intra-company or intra-fleetcampaign). In such embodiments, that fleet generally will be paying theperformance bonuses for the campaign. In other embodiments, campaignparticipants are not limited to drivers in only one specific fleet(i.e., an inter-company or inter-fleet campaign). In such an embodiment,a third party may be paying the performance bonuses for the campaign.For example, companies providing goods and services to the trucking orvehicle transportation industry may sponsor such a campaign foradvertising purposes. A particular fleet operator seeking to attract theattention of drivers in other fleets might also be a sponsor of aninter-company campaign. FIG. 14 is a block diagram indicating that block62 of FIG. 13 can encompass both intra-company campaigns, as indicatedin a block 68, as well as inter-company campaigns, as indicated in ablock 70. FIG. 15 is a block diagram indicating that the performancebonus can encompass both intra-company payouts, as indicated in a block74 (where those bonus funds are used only to pay drivers of a specificfleet), as well as inter-company payouts (where those bonus funds areused to pay any winning driver, regardless of fleet), as indicated in ablock 76.

In at least one aspect of the concepts disclosed herein, the performancemetric is designed to facilitate comparison of driver performance dataacross different fleets, and different vehicles. This will enableindividual campaigns to include more participating drivers, which inturn will bring in more advertising revenue to fund bigger performancebonuses. In at least one embodiment, such a metric is mutually agreedupon by a plurality of different fleet operators. Adoption of a commonperformance metric across multiple fleets will enable top performingdrivers to be able to show their cumulative performance scores to otherparticipating fleet operators, providing an additional tool for fleetsto use when evaluating potential new hires. Such a common performancemetric will also enable participating fleet operators to appear moreattractive as potential employers than non-participating fleetoperators, who will not be offering the drivers the potential of earningthe additional performance based income (i.e., income in addition to theindustry standard pay by the mile driver compensation).

The concepts disclosed herein encompass embodiments in which individualfleet operators host their own website, where driver rankings in thatfleet can be compared. In other embodiments, the website is hosted by athird party, and multiple fleet operators participate. The third partycan offset their costs for operating the website by chargingparticipating fleet operators a fee, and/or by advertising revenue. Insome embodiments, all driver performance data is displayed in ananonymous format, so that individual drivers cannot be identified unlessthe driver shares their user ID. In some embodiments, drivers can onlycompare their score with drivers in their own fleet, while in otherembodiments drivers can see the performance data of drivers in otherfleets.

FIG. 16 is a functional block diagram of various elements that can beemployed to implement the hosted driver performance website concept, inone exemplary embodiment. The elements includes a plurality of enrolledvehicles 148 a-148 c (noting that the concepts disclosed herein can beapplied to a different number of vehicles), a plurality of drivers 152a-152 c (noting that the concepts disclosed herein can be applied to adifferent number of drivers), a plurality of vehicle operators 156 a-156c (noting that the concepts disclosed herein can be applied to adifferent number of vehicle operators), and a remote monitoring service150. Each vehicle includes the components discussed above in connectionwith FIG. 3 (noting the number and types of sensors disclosed in FIG. 3are exemplary, and not limiting), enabling the vehicle to conveyperformance data from the vehicle to remote monitoring service 50, whichmonitors the performance data from each vehicle 148 a-148 c over time toenable the driver's performance while operating that vehicle to beevaluated. In an exemplary embodiment monitoring service 150 generates awebpage (as indicated by webpages 154 a-154 c) for each vehicleoperator, so the vehicle operator can review the performance rankings ofeach of their drivers. It should be understand that the conceptsdisclosed herein also encompass other website designs, and the webpageper fleet is not the only possible model. In one embodiment, driverswill have their own webpage 154 d (alternatively, drivers can access thewebpage for their specific fleet).

It should be understood that monitoring service 150 is implemented usinga remote computing device, and that the term remote computing device isintended to encompass networked computers, including servers andclients, in private networks or as part of the Internet. The monitoringof the vehicle/driver performance data and driver performance ranking bymonitoring service 150 can be performed by multiple different computingdevices, such that performance data is stored by one element in such anetwork, retrieved for review by another element in the network, andanalyzed by yet another element in the network.

FIG. 17 is an exemplary screen shot of a webpage accessed by a driver toreview his (or her) performance ranking. It should be understood thatthe exemplary webpage of FIG. 17 is based on having a webpage upon whichdrivers for a specific fleet can view their individual scores, as wellas the scores of other drivers in their fleet. The concepts disclosedherein specifically encompass embodiments where drivers can view onlytheir own performance rankings, in which case a different webpage designwould be employed.

Referring to FIG. 17, a webpage 100 includes a first portion 102 thatenables a driver to select a specific driver from among a plurality ofdrivers. The driver identities can be made anonymous, as shown in FIG.17 (numbers, not names), or some fleets may wish to list drivers by name(noting that privacy and consent issues for such a scheme are notdiscussed herein). It should be understood that webpage 100 can beunique to only one driver, such that portion 102 is not required. Usingnumbers to identify drivers enables individual drivers to look at thescores of their peers, without being able to individually identify whichdriver obtained what score. The driver will likely only know his or herown unique number, and thus will only be able to personally identify hisor her own score. Webpage 100 also includes a results section 104, wheredetails of the selected driver's performance ranking are disclosed. Itshould be understood that the elements shown on webpage 100 can bedisplayed on different portions of the webpage, or on different webpagesand/or different websites, instead of together. Webpage 100 alsoincludes an ad section 112, where the website host can earn revenue bydisplaying advertising, and a performance tip section 106, where thewebsite host provides tips to the driver for improving their performanceranking.

Referring to first portion 102, a driver has selected driver numberZONA0047 (noting that any type of driver identification can beemployed), such that the data displayed in results section 104 andperformance tip section 106 relate to driver ZONA0047. As shown in FIG.17, results section 104 includes results from three different campaigns,recognizing that in some embodiments drivers will be participating inmultiple campaigns (although it should be recognized that the conceptsdisclosed herein encompass embodiments where drivers participate agreater number of campaigns, or fewer campaigns, including only a singlecampaign (noting the duration of the single campaign could span thedriver's career).

Referring to results section 104, exemplary (but not limiting)information displayed herein includes details on the campaign, whetherthe campaign is inter-company or intra-company, and the driver'sperformance ranking for that campaign. A visual guide to the driver'srelative performance is displayed using a plurality of fuel pump icons(where a greater number of fuel pump icons, or other graphical icons,indicates a better performance rating). As shown, webpage 100 is basedon displaying 10 fuel pump icons for each campaign (icons 108 a-108 c),enabling the driver's performance to be graphically displayed on a scaleof 1 to 10. Thus, a driver whose performance ranking is in the top80^(th) percentile would have 8 solid or un-shadowed fuel pumps.Recognizing that while only full icons are displayed in this example,partial fuel pump icons can be used as well, to provide fractionalratings, or numbers between 0 and 10 can be rounded up to the next wholenumber. Radio buttons 110 a-c can be used by the driver to selectperformance tips for the particular campaign to be displayed in section106.

With respect to webpage 100, it should be understood that the design ofwebpage 100 is intended to be exemplary, and different webpage designscan be employed; and further, that the data on webpage 100 can beprovided to the vehicle operator on more than one webpage. If desired,access to webpage 100 can be restricted only to the fleet operatoremployer the driver and the driver themself. However, providing otherdrivers access to webpage 100 will enable drivers to see how they rankcompared to their peers, encouraging drivers to compete amongstthemselves to collect the performance bonus available in campaigns.

Referring once again to section 104 of webpage 100, note that a firstcampaign (associated with radio button 110 a) is identified asINTRA-COMPANY RANKING. This campaign is a fleet sponsored campaign forall of the fleet drivers to compete with each other for a performancebonus. Driver ZONA0047 ranks as 83^(rd) out of 225 drivers, with lowernumbers indicating better performance (i.e., the top ranking driverwould be ranked as 1, noting that the fleet operator could have reversedthe logic, such that 225 was the top ranking driver). Being the 83^(rd)lowest ranking driver out of a fleet of 225 drivers places driverZONA0047 in the top 63% ((225−83)/(225*100)=63.11%). Six fuel pump icons108 a are filled in. The campaign parameters are summarized, indicatingthat drivers having rankings from 1-25 (i.e., the top 88.89%) across theentire fleet share in the bonus pool assigned to this campaign. DriverZONA0047 needs to increase his ranking from 83^(rd) to 25^(th) in orderto be eligible for a share in the bonus pool. Note that campaigns can beconfigured such that the top 25 drivers earn equal shares of the bonuspool, and campaigns can also be configured such that higher rankingdrivers (i.e., closer to #1) earn a proportionally larger share of thebonus pool.

Referring once again to section 104 of webpage 100, note that a secondcampaign (associated with radio button 110 b) is identified asINTRA-COMPANY CAMPAIGN XYZ. This campaign is a fleet sponsored campaignfor all of the fleet drivers to compete with each other for aperformance bonus. Driver ZONA0047 has no ranking indicated in thecampaign, thus all ten fuel pump icons 108 b are shadowed or empty. Thecampaign parameters are summarized, indicating that Campaign XYZincludes a bonus pool to be shared by the 10 fleet drivers having themost improved performance scores for December 2011. Driver ZONA0047 hasselected radio button 110 b so that performance tips and additionalinformation related to Campaign XYZ are displayed in section 106. Thoseperformance tips include a first tip indicating that late shiftingreduced Driver ZONA0047's performance ranking by 9.2% over the last 14days. A second performance tip indicates that hard breaking eventsreduced Driver ZONA0047's performance ranking by 5.3% over the last 19days. Finally, the last performance tip indicates that excessive idlingon Dec. 11, 2011 disqualified Driver ZONA0047 from Campaign XYZ. Itshould be recognized that the specific performance tips shown in section106 are intended to be exemplary, and not limiting. The actualperformance tips displayed will be related to the specific campaign, anddesigned to provide feedback to individual driver's to enable them toidentify behaviors that have reduced their performance ranking.

In some embodiments section 112 includes banner ads targeted to drivers.In other embodiments section 112 includes advertising from vendors whoare sponsoring specific campaigns, or who are sponsoring hosting of thedriver performance ranking website. The advertising can be a mixture ofthose different types, and other types of advertising.

Exemplary System Environment

FIG. 18 is a functional block diagram of an exemplary system employed toimplement some of the concepts disclosed herein. The functional blockdiagram illustrates exemplary components used in each vehicle 128 thatis enrolled in a vehicle/driver performance monitoring service, toimplement some of the method steps discussed above. An exemplaryvehicle/driver performance monitoring service is based on adding anoptional data buffer 136 (or other short-term memory storage) and abi-directional data link 134 to each enrolled vehicle (in an exemplary,but not limiting embodiment, the data buffer and data link are combinedinto a single component). It should be understood that the short termmemory storage is not required for embodiments where the performancedata transmitted from the enrolled vehicle does not include operational,vehicle, or driver related data that must be briefly stored. In anexemplary embodiment, the data link is a combination radio frequency(RF) transmitter and receiver, although separate transmitters andreceivers could be used (note the term RF specifically encompassescellular telephone based data links) A data terminal can optionally beincluded in the vehicle to facilitate operator entry of information andoperator transmission of information that is presented to the operatoron a display within the vehicle. Data collected on a portable datacollection device during an inspection can also be uploaded through sucha data terminal, or independently by direct transmission to the remotemonitoring service. While RF data transmission represents an exemplaryembodiment, other types of data transmission could be employed. If thevehicle does not already include performance data/operational datacollecting components 130, such components are added. Most vehiclesmanufactured today include operational data collecting componentsalready, as many of today's vehicles are designed to use suchcontinuously generated operational data to control operation of thevehicle in real-time, and such vehicles generally include datacollecting components, data buses, and controllers that use theoperational data to control the operation of the vehicle. The vehicleincludes at least one processor 132 that performs the function ofmanaging the transmission of performance data from the vehicle to theremote monitoring service, according to one or more of the transmissionparadigms discussed herein. In embodiments where the performance dataincludes temporary storage of operational data, the processor alsoimplements the function of temporarily storing operational data fromcomponents 130 in data buffer 136 or other temporary storage, and usingbi-directional data link 134 to convey real-time performance data and/orthe buffered operational/performance data from the enrolled vehicle to aremote computing device 140 (which is used to analyze the performance ofthe vehicle and/or driver). It should be understood that those processorfunctions can be implemented by a single processor, or distributedacross multiple processors.

In some embodiments, an output 138 is also included, to provideinformation to the driver in a form that can be easily understood by thedriver. Output 138 can be implemented using a speaker providing anaudible output, and using a display providing a visual output. Note thatoutput 138 can be combined into a single component with the data bufferand the data link, so only a single additional component is added to thevehicle (recognizing that most vehicles already include the additionalrequired components, such as the operational data collecting componentsand the processor).

While not specifically shown in FIG. 18, in particularly preferredembodiments the vehicle is equipped with a GPS unit (exemplary GPS unitsare illustrated in FIGS. 6 and 20). In a related preferred embodimentthe processor, the GPS component, any buffer, and data link are combinedinto a single telematics device. Such a device will send GPS andvehicle/driver performance data to the remote computing device discussedbelow at a plurality of different times during the course of theoperation of the vehicle. In general, the telematics device willtransmit data at intervals ranging from as frequently as every 5 to 15seconds, or as rarely as every 5 minutes, recognizing that suchintervals can vary, and are intended to be exemplary, and not limiting.

As indicated in FIG. 18, remote computing device 140 (operated by themonitoring service) is logically coupled via a network 142 (such as theInternet) to a computing device 144 (such as a personal computer, atablet, or a smart phone) accessible to a driver (in embodiments wheredriver performance rankings are shared with drivers, noting only onesuch driver device is shown in the Figure; however, the monitoringservice will likely be monitoring the performance of a plurality ofdrivers, each likely having access to a different computing device 144),and a computing device 146 accessible to a vehicle operator (noting thatin at least some embodiments, the monitoring service performs themonitoring function for a plurality of different vehicleoperators/fleets). Network 142 facilitates communication betweencomputing devices 140, 144, and 146, enabling the monitoring service toefficiently communicate with drivers and vehicle operators. It should benoted that the concepts disclosed herein encompass embodiments where themonitoring service and vehicle operator are the same entity.

The concepts disclosed herein are in at least some embodiments intendedto be used by fleet owners operating multiple vehicles, and theperformance data conveyed to the remote location for diagnosis willinclude an ID component that enables each enrolled vehicle to beuniquely identified.

Exemplary Computing Environment

FIG. 19 is a functional block diagram of an exemplary computing devicethat can be employed to implement some of the method steps disclosedherein. It should be understood that the concepts disclosed hereinencompass processing of data collected at a vehicle both in the vehicleand at a remote computing device.

FIG. 19 schematically illustrates an exemplary computing system 250suitable for use in implementing the processing functions disclosedherein. Exemplary computing system 250 includes a processing unit 254that is functionally coupled to an input device 252 and to an outputdevice 262, e.g., a display (which can be used to output a result to auser, although such a result can also be stored). Processing unit 254comprises, for example, a central processing unit (CPU) 258 thatexecutes machine instructions for carrying out an analysis ofperformance data (and in some embodiments, of position data) collectedfrom enrolled vehicles, to identify mechanical faults in the enrolledvehicles. The machine instructions implement functions generallyconsistent with those described above. CPUs suitable for this purposeare available, for example, from Intel Corporation, AMD Corporation,Motorola Corporation, and other sources, as will be well known to thoseof ordinary skill in this art.

Also included in processing unit 254 are a random access memory (RAM)256 and non-volatile memory 260, which can include read only memory(ROM) and may include some form of memory storage, such as a hard drive,optical disk (and drive), etc. These memory devices are bi-directionallycoupled to CPU 258. Such storage devices are well known in the art.Machine instructions and data are temporarily loaded into RAM 256 fromnon-volatile memory 260. Also stored in the non-volatile memory areoperating system software and ancillary software. While not separatelyshown, it will be understood that a generally conventional power supplywill be included to provide electrical power at voltage and currentlevels appropriate to energize computing system 250.

Input device 252 can be any device or mechanism that facilitates userinput into the operating environment, including, but not limited to, oneor more of a mouse or other pointing device, a keyboard, a microphone, amodem, or other input device. In general, the input device will be usedto initially configure computing system 250, to achieve the desiredprocessing (i.e., to monitor vehicle performance data over time todetect a mechanical fault). Configuration of computing system 250 toachieve the desired processing includes the steps of loading appropriateprocessing software into non-volatile memory 260, and launching theprocessing application (e.g., loading the processing software into RAM256 for execution by the CPU) so that the processing application isready for use. In embodiments where computing system 250 is implementedin a vehicle, the computing system 250 can be configured to runautonomously, such that a user input device not regularly employed.

Output device 262 generally includes any device that produces outputinformation, but will most typically comprise a monitor or computerdisplay designed for human visual perception of output. Use of aconventional computer keyboard for input device 252 and a computerdisplay for output device 262 should be considered as exemplary, ratherthan as limiting on the scope of this system. In embodiments wherecomputing system 250 is implemented in a vehicle, the computing system250 can be vehicle performance data (and position data when desired)collected in connection with operation of enrolled vehicles toconfigured to run autonomously, such that a user output device notregularly employed.

Data link 264 is configured to enable data to be input into computingsystem 250 for processing. Those of ordinary skill in the art willreadily recognize that many types of data links can be implemented,including, but not limited to, universal serial bus (USB) ports,parallel ports, serial ports, inputs configured to couple with portablememory storage devices, FireWire ports, infrared data ports, wirelessdata communication such as Wi-Fi and Bluetooth™, network connections viaEthernet ports, and other connections that employ the Internet.

Note that vehicle/driver performance data from the enrolled vehicleswill be communicated wirelessly in at least some embodiments, eitherdirectly to the remote computing system that analyzes the data toevaluate the driver's performance, or to some storage location or othercomputing system that is linked to computing system 250.

It should be understood that the terms “remote computer”, “computingdevice”, and “remote computing device” are intended to encompass asingle computer as well as networked computers, including servers andclients, in private networks or as part of the Internet. Thevehicle/driver performance data received by the monitoring service fromthe vehicle can be stored by one element in such a network, retrievedfor review by another element in the network, and analyzed by yetanother element in the network. While implementation of the methodsnoted above have been discussed in terms of execution of machineinstructions by a processor (i.e., the computing device implementingmachine instructions to implement the specific functions noted above),the methods could also be implemented using a custom circuit (such as anapplication specific integrated circuit or ASIC).

The concepts disclosed herein encompass collecting data from a vehicleduring operation of the vehicle. The data collected is used to analyzethe performance of at least one of the driver and the vehicle. Inpreferred embodiments, the data is collected during operation of thevehicle and wirelessly transmitted from the vehicle during its operationto a remote computing device using a cellular phone network based datalink. The frequency of such data transmissions can be variedsignificantly. In general, more data is better, but data transmission isnot free, so there is a tension between cost and performance that issubject to variation based on an end user's needs and desires (someusers will be willing to pay for more data, while other users will wantto minimize data costs by limiting the quantity of data beingtransferred, even if that results in a somewhat lower quality data set).The artisan of skill will be able to readily determine a degree to whichdata quality can be reduced while still provide useful data set.

Exemplary GPS Device with Onboard Computing Environment

FIG. 20 is a functional block diagram of an exemplary telematics deviceadded to an enrolled vehicle to implement one or more of the methods ofFIGS. 1, 2, 7, 8 and 10.

An exemplary telematics unit 160 includes a controller 162, a wirelessdata link component 164, a memory 166 in which data and machineinstructions used by controller 162 are stored (again, it will beunderstood that a hardware rather than software-based controller can beimplemented, if desired), a position sensing component 170 (such as aGPS receiver), and a data input component 168 configured to extractvehicle data from the vehicle's data bus and/or the vehicle's onboardcontroller (noting that the single input is exemplary, and not limiting,as additional inputs can be added, and such inputs can be bi-directionalto support data output as well).

The capabilities of telematics unit 160 are particularly useful to fleetoperators. Telematics unit 160 is configured to collect position datafrom the vehicle (to enable vehicle owners to track the current locationof their vehicles, and where they have been) and to collect vehicleoperational data (including but not limited to engine temperature,coolant temperature, engine speed, vehicle speed, brake use, idle time,and fault codes), and to use the RF component to wirelessly convey suchdata to vehicle owners. The exemplary data set discussed above inconnection with calculated loaded cost per mile can also be employed.These data transmission can occur at regular intervals, in response to arequest for data, or in real-time, or be initiated based on parametersrelated to the vehicle's speed and/or change in location. The term“real-time” as used herein is not intended to imply the data aretransmitted instantaneously, since the data may instead be collectedover a relatively short period of time (e.g., over a period of secondsor minutes), and transmitted to the remote computing device on anongoing or intermittent basis, as opposed to storing the data at thevehicle for an extended period of time (hour or days), and transmittingan extended data set to the remote computing device after the data sethas been collected. Data collected by telematics unit 160 can beconveyed to the vehicle owner using RF component 164. If desired,additional memory can be included to temporarily store data id the RFcomponent cannot transfer data. In particularly preferred embodimentsthe RF components is GSM or cellular technology based.

In at least one embodiment, the controller is configured to implementthe method of FIG. 1 by using one or more of data collected from GPS 170and data from input 168. In a related embodiment, the controller isconfigured to implement the method of FIG. 2 by using one or more ofdata collected from GPS 170 and data from input 168. In yet anotherrelated embodiment, the controller is configured to implement steps ofthe method of FIG. 7.

In another embodiment, the controller is configured to implement stepsof the method of FIG. 8. Once the vehicle mass has been determined, thatdata can be added to GPS data that is transmitted to a remote computingdevice. In a related embodiment, input 168 is bi-directional, and thevehicle mass is output from the telematics device onto a vehicle databus, and can be used by an ECU to control vehicle operations. ECUs havebeen developed to use estimates of vehicle mass to control engine speedand transmission shifting, however, those estimates of vehicle mass havenot been based on GPS derived slope data, and as such those prior artvehicle mass estimations have been less accurate than the vehicle masscalculations based on GPS derived slope data as disclosed herein.

In addition to using GPS or position data to derive slope, it should benoted that if the vehicle is equipped with a multi-axis accelerometer(such as a 3-D accelerometer), that the data from the accelerometer canbe used in place of the position data to calculate slope. Essentially,the position data over time provides vectors, and the accelerometer dataprovides similar vectors. The vectors from the 3-D accelerometer can beused in place of the GPS derived vectors in Equations 1-3 discussedabove. Once slope has been determined using the 3-D accelerometer data,mass can be derived using the relationships discussed above. Performancemetrics can be similarly determined, generally as described above, usingslope derived from 3-D accelerometer data.

Where a vehicle is equipped both with a 3-D accelerometer and a positiontracking component (such as a GPS receiver), input from both sources canbe used to calculate velocity in three components (X, Y, Z or N/S, E/W,and Up/Down). Using data from two input sources may increase theaccuracy of the slope thus derived using Equations 1-3. If it isdetermined that data from the 3-D accelerometer is generally moreaccurate than data from the GPS component (or other position trackingcomponent), or vice versa, then the input data from the relatively moreaccurate source can be afforded more weight when being used to calculatethe three required velocity components (X, Y, Z or N/S, E/W, andUp/Down). In at least one embodiment encompassed by the conceptsdisclosed herein, a GPS receiver at the vehicle incorporates a 3-Daccelerometer, so both inputs (GPS and 3-D accelerometer) are availableto a processor for the calculation of the slope.

Although the concepts disclosed herein have been described in connectionwith the preferred form of practicing them and modifications thereto,those of ordinary skill in the art will understand that many othermodifications can be made thereto within the scope of the claims thatfollow. Accordingly, it is not intended that the scope of these conceptsin any way be limited by the above description, but instead bedetermined entirely by reference to the claims that follow.

The invention in which an exclusive right is claimed is defined by thefollowing:
 1. A system for producing a performance metric indicative ofa performance of a driver using at least in part slope data derived fromvehicle position data, comprising: (a) at least one vehicle dataacquisition component disposed at the vehicle, the at least one vehicledata acquisition component being configured to collect time indexedvehicle data, the time indexed vehicle data comprising: (i) positiondata; (ii) speed data; (iii) torque data; and (iv) engine speed data;and (b) at least one processor, the at least one processor beingconfigured to implement the functions of: (i) determining a slope thevehicle is traveling over at a specific point in time based on thevehicle position data at that point in time; (ii) determining a mass ofthe vehicle at a specific point in time, based on the slope the vehicleis traveling over at that point in time, the speed data at that point intime, the torque data at that point in time, and the engine speed dataat that point in time; and (iii) producing the performance metric of thedriver's operation of the vehicle based at least in part on the mass ofthe vehicle, the mass having been determined using slope data derivedfrom vehicle position data.
 2. The system of claim 1, wherein thefunction of determining the slope the vehicle is traveling over at thespecific point in time is implemented by a processor executing the stepsof: (a) determining a horizontal ground speed of the vehicle at thespecific point in time based on the position data; and; (b) determiningthe slope the vehicle is traveling over at that point in time, based onthe horizontal ground speed and Z axis position data at that point intime.
 3. The system of claim 2, wherein the at least one vehicle dataacquisition component comprises a position sensing component, and theprocessor executing the step of determining the horizontal ground speedof the vehicle uses velocity data derived from changes in position datadetermined by the position sensing component over time.
 4. The system ofclaim 1, wherein the at least one vehicle data acquisition componentcomprises a position sensing component, and the processor executing thestep of determining the mass of the vehicle uses velocity data derivedfrom changes in position data determined by the position sensingcomponent over time.
 5. The system of claim 1, wherein the at least onevehicle data acquisition component comprises a position sensingcomponent and a speed sensing component, and the processor executing thestep of determining the mass of the vehicle uses speed data generated atthe vehicle by the speed sensing component.
 6. The system of claim 1,wherein the at least one processor is configured to produce a cost perloaded mile performance metric.
 7. The system of claim 1, wherein the atleast one processor used to determine slope and vehicle mass is part ofthe vehicle.
 8. The system of claim 7, further comprising a wirelessdata link in the vehicle and a second processor disposed remote from thevehicle, wherein: (a) the at least one processor in the vehicle isfurther configured to use the data link to convey the vehicle data, theslope, and the vehicle mass to the second processor; and (b) the secondprocessor is configured to use the vehicle data, the slope, and thevehicle mass to produce the performance metric of the driver's operationof the vehicle.
 9. The system of claim 1, wherein the at least oneprocessor is disposed remote from the vehicle, and further comprising awireless data link in the vehicle to convey the vehicle data to the atleast one processor remote from the vehicle.
 10. The system of claim 1,further comprising a display in the vehicle on which the performancemetric is displayed to the driver.
 11. A vehicle telematics system foruse in a vehicle, the vehicle telematics system comprising: (a) apositioning sensing component for collecting position data from thevehicle during vehicle operation, the position data being time indexed;and (b) at least one performance metric determining component selectedfrom a group of performance metric determining components consisting of:(i) a first component comprising a processor configured to implement thefunctions of determining a slope the vehicle is traveling over at aspecific point in time based on the position data, determining a mass ofthe vehicle based on slope, speed data, torque data, and engine speeddata; and producing a driver performance metric based at least in parton the mass of the vehicle; (ii) a second component comprising awireless data link to a remote processor configured to implement thefunctions of determining a slope the vehicle is traveling over at aspecific point in time based on the position data, determining a mass ofthe vehicle based on slope, velocity data, torque data, and engine speeddata; and producing a driver performance metric based at least in parton the mass of the vehicle; and (c) a display on which the driverperformance metric is displayed to the driver.
 12. The telematics systemof claim 11, wherein: (a) the telematics device further comprises atleast one data port for receiving vehicle data from the vehicle duringoperation of the vehicle, the vehicle data comprising: (i) speed data;(ii) torque data; and (iii) engine speed data; and (b) the processor isfurther configured to implement the function of determining a mass ofthe vehicle at a specific point in time, based on the slope the vehicleis traveling over at that point in time, the speed data at that point intime, the torque data at that point in time, and the engine speed dataat that point in time.
 13. The system of claim 11, wherein the processoris further configured to provide a vehicle mass output that is used byat least one vehicle controller to control operation of the vehicle. 14.The system of claim 11, further comprising a data link for conveying thegeographical position data and vehicle mass data to a remote computingdevice.
 15. The system of claim 11, wherein the processor is furtherconfigured to implement the function of combining the vehicle data andthe position data together to produce slope corrected mass encodedposition data; and further comprising a wireless data link for conveyingthe slope corrected mass encoded position data to a remote computingdevice.
 16. A vehicle telematics system for use in a vehicle, thevehicle telematics system comprising: (a) a positioning sensingcomponent for collecting position data from the vehicle during vehicleoperation, the position data being time indexed; and (b) at least onedata port for receiving vehicle data from the vehicle during operationof the vehicle, the vehicle data comprising: (i) speed data; (ii) torquedata; and (iii) engine speed data; and (c) a processor configured toimplement the functions of determining a slope the vehicle is travelingover at a specific point in time based on the position data, determininga mass of the vehicle based on slope, speed data, torque data, andengine speed data; and producing a driver performance metric based atleast in part on the mass of the vehicle.
 17. The system of claim 16,further comprising a display on which the driver performance metric isdisplayed to the driver.
 18. The system of claim 16, wherein theprocessor is further configured to provide a vehicle mass output that isused by at least one vehicle controller to control operation of thevehicle.
 19. The system of claim 16, further comprising a data link forconveying the position data and vehicle mass data to a remote computingdevice.
 20. The system of claim 16, wherein the processor is furtherconfigured to implement the function of combining the vehicle data andthe position data together to produce slope corrected mass encodedposition data; and further comprising a wireless data link for conveyingthe slope corrected mass encoded position data to a remote computingdevice.